-
Notifications
You must be signed in to change notification settings - Fork 808
Making the scope property as fully qualified resource Id #18165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Test this change out locally with the following install scripts (Action run 19252787923) VSCode
Azure CLI
|
Dotnet Test Results 96 files - 48 96 suites - 48 42m 8s ⏱️ - 28m 23s Results for commit a22ca09. ± Comparison against base commit 066c054. This pull request removes 1924 and adds 661 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
| public void EmitFullyQualifiedResourceId(DeclaredResourceMetadata resource, IndexReplacementContext? indexContext) | ||
| { | ||
| var converterForContext = converter.GetConverter(indexContext); | ||
|
|
||
| var fullyQualifiedResourceId = converterForContext.GetFullyQualifiedResourceId(resource); | ||
| var serialized = ExpressionSerializer.SerializeExpression(fullyQualifiedResourceId); | ||
|
|
||
| writer.WriteValue(serialized); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm mistaken, the implementation looks identical to the existing function EmitResourceIdReference - can we commonize rather than creating a new one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, for pointing this out. I have renamed the existing one, just to be more explicit.
majastrz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
![]()
anthony-c-martin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
| "type": "Microsoft.Authorization/locks", | ||
| "apiVersion": "2016-09-01", | ||
| "scope": "[extensionResourceId(format('Microsoft.Storage/storageAccounts/{0}', format('{0}single-resource-name', parameters('name'))), 'Microsoft.Authorization/locks', 'single-resource-lock')]", | ||
| "scope": "[extensionResourceId(resourceId('Microsoft.Storage/storageAccounts', format('{0}single-resource-name', parameters('name'))), 'Microsoft.Authorization/locks', 'single-resource-lock')]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change appears to be fixing a bug in that extensionResourceId assumes the first parameter is a fully qualified ID. I tried deploying a template with the output [extensionResourceId('Microsoft.Authorization/roleAssignments/foo', 'RP.Namespace/type', 'bar')] at a few scopes, and it always evaluates to /Microsoft.Authorization/roleAssignments/foo/providers/RP.Namespace/type/bar. So this is not strictly a no-op but is a desired change. We must not have caught this before because extension resources on extension resources aren't very common outside of test scenarios.
Description
The PR, makes scope property fully qualified resource Id.
Checklist
Microsoft Reviewers: Open in CodeFlow